Processing system and method for transmitting data

ABSTRACT

A split protocol transmission method for transmitting data and a communication thread identifier for said data along a communication path from a source functional unit (SFU) to a destination functional unit (DFU) via zero or more intermediate functional units (IFU) is described. A data consuming functional unit (CFU) and a data producing functional unit (PFU) in the communication path directly communicate to each other by means of a handshake procedure wherein the data consuming functional unit (CFU) indicates a communication thread identifier (TID) to the data producing functional unit. The data producing functional unit provides data related to said communication thread identifier to said data consuming functional unit. Likewise a data processing system using this method is described.

The invention relates to a processing system.

The invention further relates to a method for transmitting data.

Systems on silicon show a continuous increase in complexity due to theever increasing need for implementing new features and improvements ofexisting functions. This is enabled by the increasing density with whichcomponents can be integrated on an integrated circuit. At the same timethe clock speed at which circuits are operated tends to increase too.The higher clock speed in combination with the increased density ofcomponents has reduced the area which can operate synchronously withinthe same clock domain. This has created the need for a modular approach.According to such an approach the processing system comprises aplurality of relatively independent, complex modules. In conventionalprocessing systems the modules usually communicate to each other via abus. As the number of modules increases however, this way ofcommunication is no longer practical for the following reasons. On theone hand the large number of modules forms a too high bus load. On theother hand the bus forms a communication bottleneck as it enables onlyone device to send data to the bus. A communication network forms aneffective way to overcome these disadvantages. The communication networkcomprises a plurality of partly connected nodes. Messages from a moduleare redirected by the nodes to one or more other nodes.

A message sent by a source functional unit may comprise a command or apacket of data. It is forwarded via one or more intermediate functionalunits until it arrives at the destination functional unit. Thedestination functional unit may on its turn send a message to the sourcefunctional unit. A functional unit can be any unit involved in a datastream for example a unit which performs operations on data, such as aCPU, a DSP or a VLIW, or a unit for storing data such as a memory, or aunit for transmitting data such as a router or an interface.

A split protocol is defined as a protocol where transactions are splitin a request and a response. After a transmission of a request iscompleted from a source functional unit to the first intermediatefunctional in the communication path the source functional unit canproceed with a next transmission, instead of having to wait for aresponse to that request from the destination functional unit. Thedestination functional unit will start a separate arbitration procedureif necessary to give a response. A split bus protocol is more efficientwhen a response generation at the slave takes time. Pipelining allows amaster to have multiple outstanding requests (i.e., requests waiting fora response). All transactions within the same communication thread areordered (responses are delivered in the same order as the requests forthat responses where issued by a master). Transactions with differentcommunication threads do not have any ordering constraints.

U.S. Pat. No. 6,182,183 provides a link level protocol for exchangingthe message between two subsequent functional units in the communicationpath from the source functional unit to the destination functional unit.According to the known protocol a master functional unit producesinformation, e.g. a command (Cmd), an address (Addr), or data (DataReq)and at the same time provides an identification of the thread(ReqThreadID) to which the information belongs. Likewise the slavefunctional unit may provide information (DataResp), and indicate thecommunication thread to which it belongs by an identification(RespThreadID).

It is a disadvantage of the known split, pipelined bus protocol that adata consuming functional unit only has limited control over thesequence in which it receives its data. If it has issued requests fordata for several communication threads the data producing functionalunit determines which of these threads is served first. This may havethe consequence that the requested data arrives in an order which doesnot enable an optimal functioning of the data consuming functional unit.

It is a purpose of the invention to provide an improved link levelcommunication protocol and an improved processing system using such acommunication protocol. This purpose is achieved by a method accordingto the invention as claimed in claim 1, and by a processing system asclaimed in claim 9. It is recognized by the inventors that it is inseveral circumstances advantageous if not the data producing functionalunit, but the data consuming functional unit selects the communicationthread for which information is exchanged. Hence, in a processing systemand method according to the invention on the one hand a splittransmission protocol in the communication path is applied. On the otherhand for at least one pair of a data consuming and a data producingfunctional units in the communication path which are communicating witheach other the data consuming functional unit has direct control aboutthe communication thread for which it receives data.

One example thereof is a data processing system, wherein the dataconsuming functional unit is a memory controller. A memory controllera.o. has the function to optimize the scheduling of storing/retrievinginformation from several communication threads, so that storage andretrieval can take place in a minimum amount of time. A memorycontroller according to the invention can very efficiently schedule thestorage of information, as it can itself select the order of the threadsfor which it requests information. Alternatively it would be possible toprovide the memory controller with large input buffers. This wouldenable it to receive large amounts of information from several threadsand select information from the input buffers in a suitable sequence,but this would go at the cost of a reduced silicon area for otherfunctions.

Another example where it is favorable that the data consuming functionalunit can select the process thread is where the data consumingfunctional unit is a processor arranged for executing a plurality oftasks. Each task switch may require typically several hundreds to athousand processing cycles. A task switch may typically occur if theprocessor has insufficient data available for a particular thread. In anembodiment of the invention the multitasking processor is capable ofselecting a thread for which it requires data in order to continue withthe same thread. In other words the processor schedules tasks takinginto account their read data requirements, and indicates this to thedata producing functional unit by means of the communication threadidentifier.

In this way the frequency of task switches can be reduced

These and other aspects of the invention are described in more detailwith reference to the drawing. Therein:

FIG. 1 schematically shows a data processing system,

FIG. 2 schematically shows a pair of a data producing functional unitand a data consuming functional unit in a communication path in the dataprocessing system, according to the invention,

FIG. 3 schematically shows a pair of a data producing functional unitand a data consuming functional unit in a second embodiment of the dataprocessing system according to the invention,

FIG. 4 schematically shows a pair of a data producing functional unitand a data consuming functional unit in a third embodiment of the dataprocessing system according to the invention,

FIG. 5 schematically shows a pair of a data producing functional unitand a data consuming functional unit in a fourth embodiment of the dataprocessing system according to the invention.

FIG. 1 schematically shows a data processing system, which comprises anetwork connecting a plurality of functional units. The processingsystem is arranged to transmit data and a communication threadidentifier for said data according to a split protocol along acommunication path (indicated by arrows) from a source functional unitSFU to a destination functional unit DFU via one or more intermediatefunctional units IFU1, . . . ,IFU5. By transmitting the data togetherwith a communication thread identifier, multiple unrelated transactions,having mutually different communication thread identifiers can evolveindependently.

FIG. 2 schematically shows in more detail a pair of a data consumingfunctional unit CFU and a data producing functional unit PFU. By way ofexample the data consuming functional unit CFU and the data producingfunctional unit PFU respectively are the destination functional unit DFUand the fifth intermediate functional unit IFU5 in FIG. 1.

The data consuming functional unit (CFU) and the data producingfunctional unit (PFU) in the communication path are arranged to directlycommunicate to each other by means of a handshake procedure. Therein thedata consuming functional unit PFU issues a request for data REQ andindicates a communication thread identifier TID identifying for whichcommunication thread it requests the data .It explicitly indicatesvalidness of the TID with a signal TIDVAL. Alternatively validity of therequest REQ and the communication thread identifier TID can be indicatedby a particular value of one of these signals REQ, TID. If the dataproducing functional unit PFU has the data for the requestedcommunication thread available it responds by indicating acceptance withthe signal ACCEPTP and providing the requested data RESPDAT. In anotherembodiment the data producing functional unit accepts the request in afixed number of clock cycles. A separate signal for indicatingacceptance is then superfluous.

On its turn the data consuming functional unit CFU indicates acceptanceof the data by a signal ACCEPTC. In another embodiment, where the dataconsuming functional unit always accepts the data within a fixed numberof clock cycles a separate accept signal need not be generated by thedata consuming functional unit.

FIG. 3 shows an extended protocol. The protocol is initiated in the sameway by the data consuming functional unit CFU, which provides anindication for a communication thread identifier TID and indicates thatit is valid explicitly by a signal TIDVAL, or implicitly by reserving aparticular value of the TID signal to indicate that it does notrepresent a valid communication thread. In this example the dataconsuming functional unit CFU can only issue requests for reading databy providing a particular communication thread identifier. In case thatit is desired that the data consuming functional unit CFU can also issueother commands, one or more additional request identification signalscan be added to specify the command type.

Contrary to the embodiment shown in FIG. 2 the data producing functionalunit PFU additionally can request the CFU to indicate an othercommunication thread identifier TID for which it wants to receive data.For that purpose the PFU provides a first and a second output signalACCEPTP, READY which in a preferred embodiment have the followingmeaning:

READY ACCEPTP Meaning 0 * The data consuming functional unit CFU has tocontinue indicating the communication thread identifier TID. 1 0 Thesecond functional unit (CFU) is requested to indicate anothercommunication thread identifier. 1 1 The indicated communication threadidentifier (TID) is accepted.

Issuing an acknowledge may take a number of cycles, in which time theREADY signal is kept low (0). During that time the value of the signalACCEPTP is not of importance (*). When the PFU is ready, READY is raised(1), and on the signal ACCEPTP indicates if the transaction has beenaccepted (1) or not (0). If a transaction is delayed (ACCEPTP=0), it ispossible to switch to another communication thread.

In the embodiment of FIG. 3 there is one additional signal that encodeswhether a link-level data exchange can proceed or whether it is delayed.With only one additional signal, there is only a proceed/delay feedbackpossible. This can be generalized to encode more elaborate feedback onwhy a transaction cannot proceed on a communication thread (when thereare multiple causes possible: e.g., empty/full buffers, a process notexpecting data on a communication thread is running on a CPU, etc), orhow long transactions can proceed on a communication thread (e.g., thereis enough buffering/data to proceed with at least N transactions on acommunication thread).

Still further embodiments of the invention are illustrated withreference to FIGS. 4 and 5. Therein the transmission method includes afurther handshake procedure wherein information is exchanged from thedata producing functioning unit (PFU) to the data consuming functionalunit (CFU) to exchange communication thread information. The furtherhandshake procedure is independent of the handshake procedure in whichdata is exchanged. In FIGS. 4 and 5 the signals TID, TIDVAL, RESPDAT,ACCEPTP and ACCEPTC have the meaning as described with reference to FIG.2. These signals form part of a first handshake procedure for exchangingdata for a particular communication thread indicated by the dataconsuming functional unit CFU. The communication thread informationprovided by the data producing functional unit PFU can be used by ascheduler in the CFU to schedule better the sequence of communicationthreads for which it requests data. The information can for example bethe amount of data available for that communication thread or theexpected time interval whereafter new data will become available.

In the embodiment of FIG. 4 the further handshake procedure includes aninformation request signal INFTID controlled by the data consumingfunctional unit CFU. This signal indicates a particular communicationthread for which the data consuming functional unit indicates additionalinformation. The data consuming functional unit CFU signals validity ofthe information request signal INFTID by a signal INFVAL. In a fixednumber of clock cycles the data producing functional unit PFU providesthe information TIDINFO relating to the specified communication thread.Instead of providing the information TIDINFO after a fixed number ofclock cycles, it can be provided in a variable time interval if the dataproducing functional unit PFU provides a signal indicating the validityof this information. In the embodiment of FIG. 4 the consumer functionalunit CFU polls for information with the PFU independently of thetransfer of data because that takes place in an independent handshake(TID, TIDVAL, RESPDAT, ACCEPTP, ACCEPTC).

FIG. 5 shows an embodiment wherein the PFU controls the transfer ofcommunication thread information in the further handshake procedure. ThePFU indicates a communication thread about which it has information withsignal INFTID) and provides the information with the signal TIDINFO.Validity of these signals is indicated with the signal INFVAL. The PFUmay provide the information about all communication threads at eachhandshake, but independently of the transfer of data because that takesplace in an independent handshake (TID, TIDVAL, RESPDAT, ACCEPTP,ACCEPTC). Alternatively it may provide that information for onecommunication thread at a time. In a preferred embodiment onlyinformation is provided if the status of a communication thread haschanged.

It is remarked that the scope of protection of the invention is notrestricted to the embodiments described herein. It is noted thatinformation, e.g. data for a communication thread, information about acommunication thread, can be exchanged between the processing units inseveral ways, e.g. serial, parallel or in a combination of ways.

Neither is the scope of protection of the invention restricted by thereference numerals in the claims. The word ‘comprising’ does not excludeother parts than those mentioned in a claim. The word ‘a(n)’ precedingan element does not exclude a plurality of those elements. Means formingpart of the invention may both be implemented in the form of dedicatedhardware or in the form of a programmed general purpose processor. Theinvention resides in each new feature or combination of features.

1. Split protocol transmission method for transmitting data and acommunication thread identifier for said data along a communication pathfrom a source functional unit (SFU) to a destination functional unit(DFU), the method comprising: directly communicating in thecommunication path between a data consuming functional unit (CFU) and adata producing functional unit (PFU) by means of a handshake procedure;providing a communication thread identifier (TID) from the dataconsuming functional unit (CFU) to the data producing functional unit;providing data related to said communication thread identifier from thedata producing functional unit to said data consuming functional unitwhen the data producing functional unit (PFU) accepts the communicationthread identifier; and providing another communication thread identifierfrom the data consuming functional unit (CFU) to the data producingfunctional unit (PFU) when the data producing functional unit (PFU) doesnot accept the communication thread identifier, the anothercommunication thread identifier being provided in response to a requestfrom the data producing functional unit (PFU).
 2. Method according toclaim 1, further comprising providing a separate signal (TIDVAL) fromthe data consuming functional unit (CFU) to the data producingfunctional unit (PFU) to indicate that the communication threadidentifier is valid.
 3. Method according to claim 1, wherein the dataproducing functional unit (PFU) accepts the communication threadidentifier within a fixed number of clock cycles.
 4. Method according toclaim 1, wherein the data consuming functional unit (CFU) indicates(ACCEPTC) when it has accepted the data from the data producingfunctional unit (PFU).
 5. Method according to claim 1, wherein the dataconsuming functional unit (CFU) accepts the data from the data producingfunctional unit (PFU) within a fixed number of clock cycles.
 6. Methodaccording to claim 2, wherein the data producing functional unit (PFU)provides information indicating that the data consuming functional unit(CFU) has to continue indicating the communication thread identifier(TID).
 7. Method according to claim 1, characterized by a furtherhandshake procedure wherein information is exchanged from the dataproducing functioning unit (PFU) to the data consuming functional unit(CFU) to exchange communication thread information, the furtherhandshake procedure being independent of the handshake procedure definedin claim
 1. 8. The method according to claim 2, wherein the dataproducing functional unit (PFU) provides a thread acceptation signal(ACCEPTP) when it has accepted the indication for the communicationthread (TID), and defers providing data until after it has provided thethread acceptation signal.
 9. Processing system comprising a pluralityof functional units, the processing system being arranged to transmitdata and a communication thread identifier for said data according to asplit protocol along a communication path from a source functional unit(SFU) to a destination functional unit (DFU), a data consumingfunctional unit (CFU) and a data producing functional unit (PFU) in thecommunication path being arranged to directly communicate to each otherby means of a handshake procedure, wherein the data consuming functionalunit (CFU) indicates a communication thread identifier (TID) to the dataproducing functional unit and the data producing functional unitprovides data related to said communication thread identifier to saiddata consuming functional unit, wherein the data consuming functionalunit (CFU) provides another communication thread identifier to the dataproducing functional unit (PFU) when the data producing functional unit(PFU) does not accept the communication thread identifier, and whereinthe another communication thread identifier is provided in response to arequest from the data producing functional unit (PFU).
 10. Processingsystem according to claim 9, wherein the data consuming functional unitis an application specific processor (ASP) capable of scheduling tasksbased on incoming read data.
 11. Processing system according to claim 9,wherein the data consuming functional unit is a memory controllercomprising a scheduler for providing indications of a communicationthread identifier in an order which reduces memory access time. 12.Method according to claim 1, wherein the data producing functional unit(PFU) accepts the communication thread identifier within a fixed numberof clock cycles without issuing an acceptance signal (ACCEPTP) toindicate an acceptance of the communication thread identifier. 13.Method according to claim 1, wherein the data consuming functional unit(CFU) accepts the data from the data producing functional unit (PFU)within a fixed number of clock cycles without issuing an acceptancesignal (ACCEPTC ) to indicate an acceptance of the data.
 14. Processingsystem according to claim 9, wherein the data consuming functional unit(CFU) provides a separate signal (TIDVAL) to the data producingfunctional unit (PFU) to indicate that the communication threadidentifier is valid.
 15. Processing system according to claim 9, whereinthe data producing functional unit (PFU) accepts the communicationthread identifier within a fixed number of clock cycles without issuingan acceptance signal (ACCEPTP) to indicate an acceptance of thecommunication thread identifier.
 16. Processing system according toclaim 9, wherein the data consuming functional unit (CFU) accepts thedata from the data producing functional unit (PFU) within a fixed numberof clock cycles without issuing an acceptance signal (ACCEPTO) toindicate an acceptance of the data.